Communication networks can generally be characterized as either private or public networks. In pure private networks, communications between multiple computers, located at different locations, occur via a permanent or switched network, such as a telephone network. The communicating computers typically connect directly to each other via a dialup or leased line connection, thereby emulating their physical attachment to one another. This type of network is usually considered private because the communication signals travel directly from one computer to another.
Communication over packet networks, such as the Internet, is typically not private, as the network cannot guarantee packet delivery. Such networks allow packets to be injected into, or ejected out of, their circuits indiscriminately, and/or analyzed while in transit. For normal communication this poses no real threat. However, to keep sensitive data communicated on such circuits private, the packets flowing on the circuit must be encrypted so that injected packets can be recognized and discarded to keep unauthorized parties from reading and analyzing data. These private circuits are called “tunnels.”
A virtual private network (VPN) is a private data network that makes use of tunnels to maintain privacy when communicating over a public telecommunication infrastructure, such as the Internet. The purpose of VPNs is to give server operators, such as corporations, the same capabilities that they would have if they had a private permanent or switched network. VPNs also cost much less to operate than other private networks, as they use a shared public infrastructure rather than a private one.
Data communicated on a VPN is encrypted before being sent through the public network and decrypted at the receiving end. An additional level of security involves encrypting not only the data but also the originating and receiving network addresses. Server operators today are looking at using VPNs for both extranets and wide-area intranets.
Setting up a VPN, however, is a complex task. Corporations providing VPN connectivity to their employees, typically, must go through a number of inefficient steps before a VPN network can be established between the server operator's server and an employee's client computer. First, the server operator must set up the individual's account on the server-side. To accomplish this, a VPN system administrator at the server-side, manually enters the configuration data for the new client, determines the necessary security settings, inputs the security settings into an authentication server, and configures the server-side firewall so that it will accept incoming packets from the new client. Second, the VPN system administrator has to configure the client-side by manually entering the configuration data for the new server, determining the necessary security settings, inputting the security settings, and configuring the client-side firewall so that it will accept incoming packets from the new server. No known current means exists for automatically configuring the client and server for VPN communication.
Another drawback with current systems that establish VPN communication between a client and a server, is that they typically do not allow multiple clients coupled to the same client-side modem to establish multiple VPN communication tunnels over the same modem. For example, say husband (H) telecommutes with his office (OH) using VPN over his Digital Subscriber Line (DSL) modem in his home. Wife (W) would also like to telecommute with her office (OW) a corporation distinct from OH. The standard means for establishing two VPN tunnels is to provide separate modems and telephone lines to ensure that the communication between H and OH and W and OW, remains secure and private. This system is both inefficient and costly as two sets of client-side modems, two telephone lines, and two separate Internet connections are required. A need therefore exists for a means to allow multiple clients to establish multiple VPN tunnels over the same client-side modem.
Yet another drawback with existing VPN systems is that of host name resolution. Users using a file manager, such as WINDOWS EXPLORER™, or an Internet browser, such as MICROSOFT'S INTERNET EXPLORER™, in conjunction with more recent versions of MICROSOFT WINDOWS™, can enter a string of text into a text box on the Graphical User Interface (GUI) of these applications. Depending on the particular application used, this text box may be called, among other things, a destination field, location field, address field, or URL field. Typically, users enter Uniform Resource Locators (URLs) into the text box. However, a folder or directory name anywhere on the network that the client computer is connected to, may also be entered into the text box. In fact, any string of text may be entered into the text box. A URL is a compact string representation for a resource that is available on the Internet. In general, a URL is written as follows:
[<scheme>:<scheme-specific-part>]. The <scheme> portion of the URL identifies which scheme is being utilized. Among the better known schemes are File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), the Gopher Protocol, Wide Area Information Servers (WAIS), USENET News Protocol (News), and the Prospero Directory Service (Prospero). Once the string of text has been entered into the address field and either the “enter” key depressed or the “Go” button clicked, the local client computer attempts to resolve what to display.
If the text entered is a URL, i.e., prefixed by ftp://, http://, www, etc., the client computer first searches its local cache to see if Web content, such as a Web page, associated with the URL is present on the local client computer. If it is, the associated Web content is displayed to the user. If it is not, the client computer sends out a DNS request to a DNS server dictated by the user's Internet settings, where the DNS (Domain Name System) resolves Internet domain names, such as www.company.com, into IP (Internet Protocol) addresses, such as 204.0.8.51. A DNS list of domain names and IP addresses are distributed throughout the Internet in a hierarchy of authority.
The DNS server then searches its DNS tables to locate an IP address associated with the URL. If an IP address is located, the IP address is returned to the local computer which then sends a request for the Web page (or other content, such as a file) to that IP address. If an associated IP address is not found on the DNS server, the DNS server returns a “page not found” response to the client computer.
If the text entered is a directory or folder name on the client computer, or within the network that the client computer forms a part of, and if such a directory or folder name is located, the contents of that folder or directory is displayed. If the text entered is not a directory or folder name on the client computer, or within the network that the client computer forms a part of, the text is sent to a designated search engine which conducts a search of the Internet using the text as the search term. A most likely Web page and/or a list of results located is subsequently displayed to the user. A description of this process can be found in U.S. Pat. No. 6,009,459, which is incorporated herein by reference. Selection of the search engine, most likely Web page, and the list of results is controlled by the manufacturer of the application and cannot be altered by the user.
The above mentioned text entry system works sufficiently well for a single client computer connected to the Internet. However, when using a VPN, multiple DNS servers and/or folders or directories with the same name, may coexist on the VPN. Therefore, the client computer, or its modem, has no way of intelligently determining which cache to search, which DNS server to send the request to, which search engine to use, and/or which directory or folder's contents to display. A need, therefore, exists to manage and prioritize requests entered into the text box of the above mentioned applications.
In light of the above, a less complex, less efficient, and less costly method for configuring a VPN would be highly desirable. Particularly where the resources of a service provider can be redirected to areas other than manually configuring the system. Furthermore, a VPN system that allows multiple clients coupled to the same client-side modem to establish multiple VPN communication tunnels over the same modem, would also be desirable. In addition, any advancement in host name resolution that addresses the abovementioned drawbacks would be welcomed.